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(54) Cryptographic key management method 



(57) A network system has: an application server 
(120, 121) for providing service; a client (102) for using 
the service; and a key server (1 03). The client acquires 
and stores a management cryptographic key, acquires 
a transaction cryptographic key to be used for a trans- 
action with the application server, encrypts the transac- 
tion cryptographic key with the management crypto- 
graphic key, sends the encrypted transaction crypto- 



graphic key to the key server, requests the key server 
to send back the encrypted transaction cryptographic 
key for a transaction, and decrypts the encrypted trans- 
action cryptographic key with the management crypto- 
graphic key to acquire the transaction cryptographic 
key. The key server stores the sent, encrypted transac- 
tion cryptographic key and sends the encrypted trans- 
action cryptographic key to the client in response to a 
request from the client. 
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Description 

BACKGROUND OF THE INVENTION 

Field of the Invention 5 

[0001 ] The present invention relates to techniques of 
managing keys used for electronic commerce transac- 
tions or the like by using a network. 

Description of the Related Art 

[0002] For electronic commerce transactions or the 
like over a network, authentication processes for iden- 
tifying a partner become necessary. A key or certificate 
(digital ID) is used for an authentication process. Gen- 
erally, each person creates a transaction public key pair 
(a pair of a public key and a secret key created by a 
public key cryptographic scheme) for each application 
server providing services, and manages it. Therefore, 
for credit card settlement and bank settlement, each 
person is required to manage different transaction pub- 
lic key pairs of credit card companies and banks with 
which the person has accounts. 
[0003] Servers are known which are used as agents 
for managing keys of each person. Each agent server 
executes an application to relay each person to an ap- 
plication server. One example is "Server-Based Wallet 
Security Proposal" by SETCo which is a promotion in- 
stitute of SET (Secure Electronics Transactions pre- 
pared by Visa International and MasterCard Internation- 
al). According to this proposal, the server side executes 
a wallet function (electronic settlement software used by 
consumers), and a client side accesses an application 
server such as an electronic mall via a Web browser. 
[0004] JP-A-2000-49766 discloses techniques in 
which a key management server automatically gener- 
ates keys and acquires application public key certifi- 
cates in order to reduce a load of each person required 
to manage keys for each application server. 
[0005] As described above, each person is required 
to manage keys for respective application servers pro- 
viding services such as electronic commerce transac- 
tions, and the management load is not small. 
[0006] Further, if each person possesses a plurality of 
transaction public key pairs, a large capacity of a mem- 
ory for storing those key pairs is required so that trans- 
actions from a portable terminal having a small memory 
capacity is difficult. 

[0007] Still further, according to the techniques dis- 
closed by JP-A-2000-49766, transaction public key 
pairs are generated and managed by the key manage- 
ment server itself, posing some security problem. 

SUMMARY OF THE INVENTION 

[0008] It is an object of the present invention to pro- 
vide a key management method capable of reducing a 
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load of key management by each person even if keys 
of respective application servers providing services are 
required to be managed, facilitating transactions from a 
portable terminal, and guaranteeing security. 
[0009] A network system achieving the above object 
has application servers providing services, clients re- 
ceiving services, and a key server. The client acquires 
and stores a management cryptographic key, acquires 
a transaction cryptographic key to be used for a trans- 
action with the application server, encrypts the transac- 
tion cryptographic key with the management crypto- 
graphic key, sends the encrypted transaction crypto- 
graphic key to the key server, requests the key server 
to send back the encrypted transaction cryptographic 
key for a transaction, and decrypts the encrypted trans- 
action cryptographic key with the management crypto- 
graphic key to acquire the transaction cryptographic 
key. The key server stores the sent, encrypted transac- 
tion cryptographic key and sends the encrypted trans- 
action cryptographic key to the client in response to a 
request from the client. When a plurality of transaction 
cryptographic keys different for respective application 
servers are prepared, the client encrypts each transac- 
tion cryptographic key with the same management cryp- 
tographic key. 

[0010] The above and other objects, features and at- 
tendant advantages of the present invention will more 
easily be understood by reading the following descrip- 
tion of the preferred embodiments thereof, taken, only 
by way of example, in conjunction with the accompany- 
ing drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0011] 

Fig. 1 is a diagram showing the structure of a sys- 
tem according to a first embodiment of the inven- 
tion. 

Fig. 2 is a diagram showing the structure of a sys- 
tem according to a second embodiment of the in- 
vention. 

Fig. 3 is a diagram showing the structure of a sys- 
tem according to a third embodiment of the inven- 
tion. 

Fig. 4 is a diagram showing the structure of a sys- 
tem according to a fourth embodiment of the inven- 
tion. 

Fig. 5 is a flow chart illustrating generation of a man- 
agement key of a person at a client according to the 
first embodiment. 

Fig. 6 is a flow chart illustrating generation and reg- 
istration of a transaction key at a client according to 
the first embodiment. 

Fig. 7 is a flow chart illustrating a transaction by a 
client according to the first embodiment. 
Fig. 8 is a flow chart illustrating terms verification 
(notification of a valid term) at a key management 
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server. 

Fig. 9 is a flow chart illustrating terms verification 
(notification of the maximum number of use times) 
at the key management server. 
Fig. 1 0 is a flow chart illustrating generation and reg- 5 
istration of a transaction key at a client according to 
the third embodiment. 

Fig, 1 1 is a flow chart illustrating authentication of a 
transaction public key at a key management server 
according to the third embodiment. 
Fig. 12 is a flow chart illustrating generation of a 
management public key and registration of a public 
key in a key management server at a client accord- 
ing to the fourth embodiment. 
Fig. 1 3 is a flow chart illustrating a transaction after 
person authentication for acquiring a transaction 
public key pair according to the fourth embodiment. 
Fig. 14 is a flow chart illustrating a person authen- 
tication process at the key management server ac- 
cording to the fourth embodiment. 
Fig. 15 is a diagram showing the form of transaction 
key indices. 

Fig. 16 is a diagram showing the form of business 
partner indices. 

Fig. 17 is a diagram showing the form of person 
management public key indices. 

DESCRIPTION OF THE EMBODIMENTS 

[0012] Now, the present invention will be described in 
conjunction with what is presently considered as pre- 
ferred or typical embodiments thereof by reference to 
the drawings. In the following description, like reference 
characters designate like or corresponding parts 
throughout the several views. 

1 . First Embodiment 

[0013] Fig. 1 is a diagram showing the structure of a 
system according to the first embodiment of the inven- 
tion. In the first embodiment, each client possesses 
business partner indices. A client 102, a key manage- 
ment server 103, an application server No. 1 120, and 
an application server No. 2 121 are connected to a net- 
work 111 via wires or radio waves. 
[001 4] Different cryptographic schemata may be used 
for communications between the client and application 
No. 1 and between theclient and application No. 2. Even 
if both the communications use the same cryptographic 
scheme, it is preferable to use different cryptographic 
keys in order to improve security. The embodiment uses 
different cryptographic keys for respective communica- 
tion partners, and provides a method and system for 
managing cryptographic keys easily and safely. 
[0015] Although not shown, the network 111 may con- 
nect a certification authority (CA). 
[0016] The client 102 is a personal computer, a port- 
able terminal, a portable telephone or the like used by 



each person 101 and having a communication function. 
The client is assigned an ID unique in the system. The 
client 102 has a key generator unit 112, a cryptographic 
process unit 113, a key register unit 114, a transaction 
judgement unit 1 1 5, a transaction execution unit 1 1 6 and 
a storage medium 117. The key generator unit 112 gen- 
erates a key management key 1 1 8 and transaction pub- 
lic key pairs 105 and 106 for the person. The crypto- 
graphic process unit 1 1 3 encrypts the transaction public 
key pairs 105 and 106 generated by the key generator 
unit 1 1 2 with the key management key 118, and decrypts 
the encrypted transaction public key pairs 105 and 106 
acquired from the key management server 1 03 with the 
key management key 118. The key register unit 1 1 4 reg- 
isters the encrypted transaction key pairs 1 05 and 1 06 
in the key management server 103. 
[0017] The transaction judgement unit 115 receives a 
report of the use terms such as a valid term and the max- 
imum number of use times of the transaction public key 
pairs 105 and 106 from the key management server 
1 03, and judges whether or not a transaction is execut- 
ed. If the transaction judgement unit 115 judges that a 
transaction is executed, the transaction execution unit 

1 1 6 executes the transaction with the application server 
No. 1 120 and application server No. 2 121 by using the 
transaction public key pairs 105 and 1 06 acquired from 
the key management server 1 03 and decrypted by the 
cryptographic process unit 113. The storage medium 

117 stores the key management key 11 8 and business 
partner indices 119 indicating the correspondence be- 
tween transaction public key pair and each application 
server. 

[0018] The key management server 103 has a key 
storage unit 1 04, a key index unit 1 07, a key register unit 
1 08, a terms verification unit 1 09 and a key provider unit 
110. The key storage unit 104 stores the transaction 
public key pairs 105 and 106 (encrypted with the key 
management key 1 1 8) requested to be registered by the 
client 102. It also stores a key use history 122. The key 
index unit 107 has indices indicating the relation be- 
tween a registered key, a person, and a business part- 
ner, the contents of the indices being shown in Fig. 15 
(to be described later). The key register unit 108 regis- 
ters the transaction public key sent by the client 1 02 in 
the key storage unit 1 04 and updates the key index unit 
107. The terms verification unit 109 verifies the valid 
term, the maximum number of use times and the like of 
the transaction public keys 1 05 and 1 06, and if the valid 
term expires or if the use time exceeds the maximum 
number or the like, this effect is notified to the client 1 02. 
The key provider unit 1 1 0 transmits the transaction pub- 
lic key pair registered in the key storage unit 1 04 to the 
client 1 02 in response to a request from the client 1 02. 
[0019] Although the key management key 118 is 
shown in Fig. 1 as a pair of a secret key and a public 
key of the public key cryptographic scheme, it is not lim- 
ited thereto but it may be a single common key of the 
common key cryptographic scheme. 
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[0020] Also, the transaction public key pairs 1 05 and 
1 06 shown in Fig. 1 may be a single common key of the 
common key cryptographic scheme for each communi- 
cation partner. 

[0021] Each unit shown in Fig. 1 is realized by a soft- 
ware program or a table. The cryptographic process unit 
may be realized by an exclusive processor. 
[0022] The operation of the system of the first embod- 
iment described above will be described with reference 
to the flow charts. 

[0023] Fig. 5 is a flow chart illustrating generation of 
the management key 118 of a person in the system 
shown in Fig. 1 . When a start of generation of the man- 
agement key 118 is instructed by a person 101 at the 
client 102 (Step 501), the key generator unit 112 of the 
client 1 02 shown in Fig. 1 generates a cryptographic key 
(Step 502). As cryptographic technologies, RSA crypto- 
graphic technologies, elliptic curve cryptographic tech- 
nologies and the like already well-known as public key 
cryptographic technologies can be utilized. Common 
key cryptographic technologies can also be used. The 
generated cryptographic key 1 1 8 is stored in the storage 
medium 117 (Step 503). The storage medium 117 may 
be a magnetic disc, a RAM, an IC card or the like. 
[0024] Fig. 6 is a flow chart illustrating generation and 
registration of transaction keys 105 and 1 06 of the sys- 
tem shown in Fig. 1 . When a start of generation and reg- 
istration of a transaction key is instructed by a person 
1 01 at the client 1 02 (Step 601 ), the key generator unit 
1 1 2 of the client 1 02 shown in Fig. 1 generates a trans- 
action public key pair (Step 602). Also in this case, cryp- 
tographic technologies similar to those used for the 
management key are utilized. In this example, it is as- 
sumed that the public key cryptographic system is used. 
[0025] Next, the client 1 02 checks whether the appli- 
cation server using this public key pair is registered in 
the business partner index unit 119 of the storage me- 
dium 117 (Step 603). If not registered, the application 
server is added to the business partner index unit 119 
as a new business partner (Step 604). 
[0026] Next, the client 102 acquires a business part- 
ner index number (business partner ID) (Step 605). The 
cryptographic process unit 113 encrypts the transaction 
public key pair generated at Step 602 with the manage- 
ment key 110 stored in the storage medium 117 (Step 
606). The encrypted transaction key pair, a personal ID, 
the transaction ID, and the use terms such as the valid 
term and the maximum number of use times of the key, 
are transmitted to the management server 1 03 which in 
turn stores them in the key storage unit 1 04 (Step 607). 
[0027] A registration instruction for a business 1 part- 
ner and the use terms of the key can be interactively 
entered by the person 1 01 from a display device and an 
input device (both not shown) of the client 102. If the 
public key is made public via CA, the public key and nec- 
essary information are sent to CA. 
[0028] Fig. 7 is a flow chart illustrating a transaction 
to be executed by the system shown in Fig. 1. When a 



start of execution of a transaction is instructed (Step 
701 ), the client 1 02 searches the business partner index 
unit 1 1 9 stored in the storage medium 1 1 7 to acquire the 
business partner index number (business partner ID) of 

5 the application server to be accessed (Step 702). For 
example, in the business partner indices shown in Fig. 
16, the person 101 can identify each business partner 
ID like "if a transaction with Bank A is to be executed, 
the business partner ID is 001". Next, the personal ID 

io and business partner ID are transmitted to the key man- 
agement server 103 to request to send back the trans- 
action public key pair (Step 703). Since the acquired 
transaction public key pair is encrypted, this public key 
pair is decrypted with the management key 118 of the 

15 person (Step 704). By using the decrypted transaction 
public key, the transaction with the application server is 
executed (Step 706). 

[0029] The key acquisition request to the key man- 
agement server 1 03 may be interactively performed by 
20 the person 101 via the display/input device of the client 
102, or it may be implemented in an application server 
transaction protocol. 

[0030] Fig. 8 is a flow chart illustrating an operation of 
checking the valid term and notifying its expiration, to 

25 be executed by the terms verification unit 1 09 of the key 
management server 1 03 of the system shown in Fig. 1 . 
In a process (Step 801 ) of terms verification (notification 
of a valid term) by the key management server 1 03, the 
valid term of the key which was transmitted at the same 

30 time when the client 1 02 requested to register the trans- 
action public key pair, is registered in the key index unit 
107 shown in Fig. 15 (Step 802). 
[0031] Thereafter, a timer notification process (Step 
804) is repetitively executed at a predetermined time in- 

35 terval. In this timer notification process, the valid terms 
of all transaction public key pairs registered in the key 
index unit 107 are checked (Step 805). If there is any 
transaction public key pair whose valid term expired, the 
valid term expiration is notified to the client having the 

40 expired transaction public key pair (Step 806). There- 
fore, the person 101 is not required to always confirm 
the valid term expiration of the transaction key, but when 
the notice is received, the transaction public key pair is 
generated (updated) to continuously use the valid public 

45 key pair. 

[0032] In this example, although the notice is given 
when the valid term expires, the notice may be given 
during a predetermined period before the valid term ex- 
piration. An e-mail may be used for such notification. 

so [0033] Fig. 9 is a flow chart illustrating an operation of 
checking the number of use times and notifying that the 
number of use times exceeds the maximum number, to 
be executed by the terms verification unit 1 09 of the key 
management server 1 03 of the system shown in Fig. 1 . 

55 The maximum number of use times of a transaction pub- 
lic key pair transmitted from the client 102 at the same 
time when the client 1 02 requested to registerthe trans- 
action public key pair, is registered in advance in the key 
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index unit 107 shown in Fig. 15. As shown in Fig. 15, 
the key management in the unit of time becomes pos- 
sible if the maximum number of cumulative use times 
1 51 0, the maximum number of use times per day 1511, 
the maximum number of use times per week 1512 and 
the maximum number of use times per month 1513 are 
registered. Depending upon use conditions, another 
unit of time may be used. 

[0034] The terms verification (notification of the max- 
imum number of use times) process to be executed by 
the key management server 1 03 shown in Fig. 9 is ac- 
tivated when an acquirement request for the transaction 
public key pair is received from the client. When this 
process starts (Step 901 ), the transaction public key pair 
is allowed to be used, i.e., the transaction public key pair 
is sent to the client (Step 902) and the numbers of use 
times 1505 to 1507 are incremented (counted up) by 1 
(Step 903). In this case, if the current time is the end 
time of each of the day, week or month, the counters for 
the numbers of use times 1505 to 1507 are cleared to 
zero and then counted up by 1 . Next, the maximum num- 
bers of use times of each time unit (day, week and 
month) are checked (Step 904). If there is any number 
of use times exceeding the maximum number, a notice 
that the number of use times exceeded the maximum 
number is notified to the client with the person possess- 
ing the corresponding transaction public key pair (Step 
905). In this case, the number of use times, the last use 
time and use history are also sent upon request. 
[0035] Upon reception of the notice that the number 
of use times exceeded the maximum number, the per- 
son 1 01 compares the received data with the number of 
use times, last use time and use history recorded by the 
person to thereby judge if there is an illegal use. If it is 
judged that there is an illegal use, the person 1 01 is re- 
quired to change the transaction public key pair regis- 
tered in the key management server 103 and the addi- 
tional information such as a password of the key man- 
agement server 103. The person 101 may inquire the 
key management server 1 03 to acquire the key use sta- 
tus information such as the number of use times, last 
use time and use history and judge if there is an illegal 
use, not only when a report (step 905) indicating the 
number of use times exceeded the maximum number is 
received, but also at any time desired by the person 1 01 
independently from the key acquirement request. 
[0036] Fig. 1 5 shows an example of the key index unit 
107 in the key management server 103. The key index 
unit is constituted of: a key ID 1501 for identifying a 
transaction public key pair; a personal ID 1 502 for iden- 
tifying a key owner; a business partner ID 1503 for iden- 
tifying a business partner application server; a counter 
1504 for counting the number of cumulative key use 
times; a counter 1505 for counting the number of use 
times per day; a counter 1506 for counting the number 
of use times per week; a counter 1 507 for counting the 
number of use times per month; a status flag 1508 indi- 
cating whether the key use is permitted or inhibited; a 



field 1509 for setting the last key use day and time; a 
field 1510 for setting a key valid term; a field 1511 for 
setting the maximum number of cumulative use times; 
a field 1512 for setting the maximum number of use 
s times per day; a field 1513 for setting the maximum 
number of use times per week; a field 1514 for setting 
the maximum number of use times per month; and the 
like. 

[0037] The key index unit 107 may also contain a 
io pointer to the storage address of a key, and a crypto- 
graphic system name. 

[0038] Fig. 1 6 shows an example of the business part- 
ner index unit 119. The business partner index unit is 
constituted of a business partner ID 1601 for identifying 
15 a business partner application server, a business part- 
ner name 1 602, an application server name 1 603, busi- 
ness contents 1 604 and the like. 

2. Second Embodiment 

20 

[0039] Another embodiment will be described. Only 
different points from the first embodiment will be de- 
scribed. 

[0040] Fig. 2 is a diagram showing the system accord- 
25 ing to the second embodiment of the invention , the sys- 
tem having a business partner index unit 21 9 in the key 
management server 1 03. Although the business partner 
index unit 1 1 9 of the first embodiment exists in the stor- 
age medium 117 of the client 102, the business partner 
30 index unit 21 9 exists in the key management server 1 03. 
[0041] In the first embodiment, business partner ID's 
are assigned and managed independently by each cli- 
ent, whereas in the second embodiment, business part- 
ner ID's are assigned and managed by the key manage- 
rs ment server 1 03 and determined uniquely in the system. 

3. Third Embodiment 

[0042] The third embodiment will be described. Only 
40 different points from the second embodiment will be de- 
scribed. In the third embodiment, the key management 
server 1 03 has a partial function of CA to authenticate 
the transaction public key. 

[0043] Fig. 3 is a diagram showing the structure of a 
45 system according to the third embodiment of the inven- 
tion. In this embodiment, the public key of a transaction 
public pair key is registered in the key management 
server without encrypting it. As compared to Fig, 2, a 
public key authentication unit 323 is added to the key 
so management server 1 03. Since the public key of a trans- 
action public key pair is not encrypted, the key manage- 
ment server 1 03 can authenticate the transaction public 
key of the person 101 when another client, an applica- 
tion server 120 or 121 requests for verification of the 
55 transaction public key. 

[0044] Fig. 10 is a flow chart illustrating generation 
and registration of transaction keys 105 and 106 of the 
system shown in Fig. 3, in which encryption of only the 
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secret key of the transaction key pair is performed in the 
system having the business partner index unit 21 9 in the 
key management server 1 03. Steps 1 002 and 1 003 are 
similar to Steps 602 and 603 shown in Fig. 6, and Steps 
1 004 to 1 008 are similar to Steps 603 to 607 shown in 5 
Fig. 6. Different points from Fig. 6 reside in that when 
the business partner index unit 21 9 is searched, not the 
business partner index unit of the client but the business 
partner index unit 219 of the key management server 
103 is searched (Step 1003), and only the secret keys 
of the transaction public key pairs 1 05 and 1 06 are en- 
crypted with the management key 118 of the person 
(Step 1007). 

[0045] Fig. 11 is a flow chart illustrating authentication 
of public keys of the transaction public key pairs 1 05 and 
1 06 registered without encryption in the flow chart of Fig. 
10, the authentication being executed by the key man- 
agement server 103 of the system shown in Fig. 3. In 
this example, it is assumed that the application server 
No. 1 120 requests for verification of the transaction 
public key of the person 1 01 . 

[0046] The verification request includes an ID of a per- 
son who made public the public key, the name (or ID) of 
a server who requested the verification, and the public 

key. 

[0047] When the server 1 03 receives a verification re- 
quest, authentication process of the transaction public 
key starts (Step 1101). The server 1 03 analyzes the ver- 
ification request for the transaction public key (Step 
1 1 02), and searches the transaction public key pair cor- 
responding to the application server No. 1 120 and per- 
sonal ID from the business partner index unit 21 9 to find 
the public key (Step 1 1 03). This public key is compared 
with the public key sent from the application server No. 
1 120 (Step 1104). If both the keys coincide with each 
other, a verification success is notified to the application 
server No. 1 120 (Step 1106). If both the keys do not 
coincide, a negation is notified (Step 1107). 
[0048] This procedure may be performed in the pro- 
tocol when a transaction starts between the server and 
client. 

4. Fourth Embodiment 

[0049] The fourth embodiment will be described. Only 
different points from the third embodiment will be de- 
scribed. Also in this embodiment, the key management 
server 103 has a partial function of CA to authenticate 
a person accessed to the key management server 1 03. 
[0050] Fig. 4 is a diagram showing the structure of a 
system according to the fourth embodiment of the in- 
vention. In this embodiment, the public key of a key man- 
agement public key pair is registered in the key man- 
agement server. 

[0051] The key management key 118 stored in the 
storage medium 1 1 7 of the client 1 02 is a public key pair. 
A person authentication unit 426 is added to the key 
management server 1 03, and a key management public 



key 423 which is the public key of the key management 
key pair 118 is stored in the key storage unit 104. The 
person authentication unit 426 receives a person certif- 
icate signed with the secret key of the key management 
key pair 118 from the client 102 and verifies it using a 
key management public key 423. The key management 
server 103 has a management key index unit 424 for 
managing key management public keys. 
[0052] Fig. 12 is a flow chart illustrating generation 
and registration of the management key 1 1 8 of the per- 
son in the system shown in Fig. 4, i.e., an operation of 
registering the public key of the public key pair 118 in 
the key management server 1 03 as the key 423. Steps 
1202 and 1203 are similar to Steps 502 and 503 shown 
in Fig. 5. Different points from Fig. 5 reside in that the 
key management key is generated always as a public 
key pair (public key and secret key) (Step 1 202) and the 
public key of the key management public key pair 118 
of the person is registered in the key management serv- 
er as the key 423 (Step 1204). 
[0053] Fig. 13 is a flow chart illustrating a transaction 
at the client 102 of the system shown in Fig. 4. Steps 
1304 to 1306 are similar to Steps 703 to 705 shown in 
Fig. 7. Different points from Fig. 7 reside in that before 
a transaction, a person certificate signed with the secret 
key of the key management public key pair 118 is sent 
to the key management server 103 (Step 1302). If OK 
of person authentication is returned from the key man- 
agement server (Step 1303), the processes similar to 
Fig. 7 are performed. If NG of person authentication is 
returned, the transaction cannot be executed. 
[0054] Fig. 1 4 is a flow chart illustrating a person au- 
thentication process to be executed by the key manage- 
ment server 1 03 of the system shown in Fig. 4. 
[0055] The person authentication process starts 
when the person sends a person authentication request 
together with a digitally signed certificate to the key man- 
agement server 103 (Step 1401). The person authenti- 
cation request is analyzed (Step 1402). The signature 
of the sent person certificate is decrypted with the key 
management public key 423 registered in the key man- 
agement server 1 03 to verify the person certificate (Step 
1403). If verification OK, person authentication OK is re- 
turned to the client 1 02 (Step 1 405) to permit the trans- 
action public key acquisition request using the personal 
ID (Step 1406), whereas if verification NG, negation of 
person authentication is returned to the client 102 (Step 
1407) so as not to permit the transaction public key ac- 
quirement request using the personal ID (Step 1408). 
As shown in Fig. 15, the key index unit 107 has a flag 
1508 indicating the permission/inhibition of the key ac- 
quirement. 

[0056] Fig. 1 7 shows an example of the management 
key index unit 424 possessed by the key management 
server 103. The management key index unit includes a 
management key ID 1701 for identifying the manage- 
ment key, a personal ID 1702 for identifying an owner, 
and management key information 1703 containing ad- 
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ditional information of the management key such as the 
type of a cryptographic system. 

5. Modifications 

[0057] In the embodiments, although key generation 
is performed inside the client 1 02, it may be performed 
by an apparatus other than the client. 
[0058] In transactions via a network, an electronic cer- 
tificate issued by a Certificate Authority is used in some 
cases in order to authenticate each individual. The key 
management server may store and manage an elec- 
tronic certificate as well as the key. 
[0059] Many modifications and variations of the 
present invention are possible in the light of the above 
techniques, it is therefor to be understood that with the 
scope of the appended claims, the invention may be 
practiced otherwise than as specifically described. 



Claims 

1 . A cryptographic key management method compris- 
ing steps of: 

generating and storing a management crypto- 
graphic key; 

generating a transaction cryptographic key; 
encrypting the transaction cryptographic key 
with the management cryptographic key; and 
storing the encrypted transaction cryptographic 
key in a key management server (1 03). 

2. A cryptographic key management method accord- 
ing to claim 1, wherein if a plurality of transaction 
cryptographic keys are generated, each of the 
transaction cryptographic keys is encrypted with the 
management cryptographic key. 

3. A cryptographic key management method accord- 
ing to claim 1 , further comprising steps of: 

acquiring the encrypted transaction crypto- 
graphic key from the key management server; 
decrypting the encrypted transaction crypto- 
graphic key with the management cryptograph- 
ic key; and 

acquiring the transaction cryptographic key. 

4. A cryptographic key management method accord- 
ing to claim 1 , wherein the transaction cryptograph- 
ic key is a pair of a public key and a secret key of a 
public key cryptographic scheme. 

5. A cryptographic key management method accord- 
ing to claim 4, wherein: 

the secret key of the transaction cryptographic 



key is encrypted with the management crypto- 
graphic key and the encrypted secret key and 
the plaintext public key are stored in the key 
server; and 

5 the key server checks whether a received pub- 

lic key is coincident with the stored public key, 
and notifies the check result to a public key 
sending site. 

10 6. A cryptographic key management method accord- 
ing to claim 3, wherein: 

the management cryptographic key is a pair of 
a public key and a secret key of a public key 
'5 cryptographic scheme, and the public key of the 

management cryptographic key is stored in the 
key server; and 

the key server authenticates a requesting site 
requesting for acquisition of the transaction 
20 cryptographic key, by using the stored public 

key. 

7. A network system comprising: 

25 an application server (120, 121) for providing 

services; 

a client (102) for using the services; and 
a key server (103), 
wherein: 

30 said client acquires and stores a management 

cryptographic key, acquires a transaction cryp- 
tographic key to be used for a transaction with 
said application server, encrypts the transac- 
tion cryptographic key with the management 

35 cryptographic key, sends the encrypted trans- 

action cryptographic key to said key server, re- 
quests the key server to send back the encrypt- 
ed transaction cryptographic key for the trans- 
action, and decrypts the encrypted transaction 

40 cryptographic key with the management cryp- 

tographic key to acquire the transaction crypto- 
graphic key; and 

said key server stores the sent, encrypted 
transaction cryptographic key and sends the 
45 encrypted transaction cryptographic key to said 

client in response to a request from the client. 

8. A network system according to claim 7, wherein 
when said client acquires a plurality of transaction 

so cryptographic keys different for said respective ap- 
plication servers, said client encrypts each of the 
transaction cryptographic keys with the manage- 
ment cryptographic key. 

55 9. A network system according to claim 7, wherein: 

said client sends a valid term of the encrypted 
transaction cryptographic key together with the 
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encrypted transaction cryptographic key to the 
key server; and 

said key server notifies an expiration of the val- 
id term of the transaction cryptographic key. 

5 

10. A network system according to claim 7, wherein: 

said client sends the maximum number of use 
times of the transaction cryptographic key to- 
gether with the encrypted transaction crypto- '0 
graphic key to said key server; and 
said key server counts the number of acquisi- 
tion requests for the encrypted transaction 
cryptographic key and notifies uses over the 
maximum number to said client. '5 

11. A network system according to claim 7, wherein: 

the management cryptographic key is a pair of 
a public key and a secret key of a public key 20 
cryptographic scheme; 

said client stores the public key of the manage- 
ment cryptographic key in said key server; and 
said key server authenticates a requesting site 
requesting acquisition of the management 25 
cryptographic key by using the stored public 
key, and if authentication succeeds, sends the 
transaction cryptographic key to said request- 
ing site. 



12. A network system according to claim 7, wherein: 



30 



the transaction cryptographic key is a pair of a 
public key and a secret key of a public key cryp- 
tographic scheme; 35 
said client encrypts the secret key of the trans- 
action cryptographic key with the management 
cryptographic key and stores the encrypted se- 
cret key and the plaintext public key in said 
server; and 40 
said server checks whether the public key sent 
from said application server is coincident with 
the stored public key of said client and notifies 
the check result to said application server. 

45 



50 



55 
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